大家都是程序员，接到同样的工作任务，有人每天忙碌加班弄到身心俱疲却还无法完成，而有人不仅能按时保质保量完成工作，还能有自己的时间健身、学习和充电。是什么原因导致这样的差别呢？小米的创始人雷军有一句名言：不要用战术上的勤奋掩盖战略上的懒惰。天道不一定酬勤，比勤奋更重要的是通过深度思考，找到正确的道路，然后借用巧方法、好工具帮助自己更快到达目的地。

本文将通过解答以下 8 个问题，和大家一起探讨如何提高工作效率。

1. 写代码是应该写一行，编译一行吗？ 2. 拿到一个需求却不知从那里开始，面对一堆需求，先做哪些功能呢？ 3. 研发中踩过的坑，如果有效避免第二次掉坑？ 4. 常常为了一个小小的错误用了很长的时间，不知从那里查，也查不出结果，对于偶现或是小错误，是否值得投入、评判标准是什么？ 5. 常常做出来的程序，涉及到需求变动就挠头，怎么在程序设计阶段，考虑好扩展性？ 6. 熬夜赶工，是否可取？ 7. 一个功能，要不要自测，自测要多久，为什么 RD 排斥自测？ 8. 团队协同开发，如何向上或向下管理，提高开发效率？

一、写代码是应该写一行，编译一行吗？

不瞒大家，刚入行时，我写代码的习惯就是写好一行，编译一行，运行一行，自测一行，这样写代码效率当然很低下，一个简单逻辑，就需要写大半天，这里的写一行编译一行，描述的有点夸张，记得我初学一门语言时大多数情况都是一行一行的写，因为我还不确定每行代码，程序会怎么执行，会产生怎样的输出？

如果你还处于我刚说的这个阶段，那么，你正在蹒跚学步。在这个阶段，你一定要用心，多写多练，明白你写的每一行代码会产生怎样的输出，尽量做到熟能生巧。

如果你熟知每行代码的输出，仍然写一行，编译一行，进行着低效的劳作，这时候你就需要给自己一点自信啦，就像很多人早上出门去上班，要确认门有没有锁好，每天要确认 180 次自己带手机没？带家门钥匙没？身份证还在钱包里不？不光不相信自己，团队小伙伴提交一行代码，这些人都需要 72 次确认，这行代码是不是可运行，别笑，生活中这种人很多，在我的职业生涯中，也遇到了很多类似的程序员，他们写代码本身就很严谨，遵从谷歌公司代码规则，遵从团队编码约定，反复训练，可以做到和上公交就掏出公交卡一样熟练，但他们仍然需要反复确认，自己的代码成员变量命名是否为驼峰，指针变量生命周期管理是否合理无漏洞。

大家都写过高考作文，写代码其实可以像写作文一样，初学者写的是句子，想一句写一句，厉害了想一段，写一段，作文写的好的，大部分都会打个提纲，总体想一下，一气呵成，最多检查几个错别字。

程序开发，切忌上来就写，想到哪里写到哪里，一段好的代码并不是它们越复杂越好，简单实现复杂功能才是我们最需要的，linux 内核代码虽大，但是那些精典的算法实现的代码精炼的不能再精炼了。要提高编码速度更重要的是简化梳理程序流程，以最小的代码量完成功能。所以编程最重要的事情是思考。

当思考好，几乎所有步骤后再写，基本上就是码代码，然后调试改 bug 的过程。

如果你熟练各种语法，还在写一行，编译一行，基本上就是没经过系统思考，就开始一通乱写，这样效率真的会很低。

建议写代码前，思考，然后把框架写出来，写框架的时候，可以只写方法，不写实现，仅在方法内，多写几个 TODO，写明输入哪些参数，输出哪些参数，把框架整理几遍后，再一个个的把 TODO 函数实现写好，一次编译！

如果系统很复杂，那就一个一个模块的实现，然后一次编译。

二、拿到一个需求却不知从那里开始，面对一堆需求，先做哪些功能呢？

面对一堆需求，需要先对需求进行优先级排序。

判断一个需求的优先级，主要是从三个方面：产品战略定位、用户影响、技术实现。通过重要性和紧急度两个指标进行排序，综合对比衡量确定某需求优先级，成本也需要纳入指标进行考量。

当然作为一名 RD，产品功能需求优先级是PM根据以上或者其他考虑，预定好的。作为一名 RD，也需要有产品思维，根据自己对技术的了解，提出自己的技术方案，可行性分析，估时等等数据，供 PM 确定需求优先级.

然而我想说的是，不必把每个需求模块都做完，憋个大招，三四天程序仍然是编写中，不可运行状态。

尤其是在需求不明确的情况下，宜采用快速原型模型开发的开发方法，快速设计开发出软件系统的原型，该原型向用户展示待开发软件的全部或部分功能和性能；用户对该原型进行测试评定，给出具体改进意见以丰富细化软件需求；开发人员据此对软件进行修改完善，直至用户满意认可之后，进行软件的完整实现及测试、维护。

把握主线需求，不断细化是快速出活的一大妙招。

重要事情再说一次吧 … 切忌拿到一个模块直接想着出细活，除非需求很明确，时间要求又不太紧张，否则你会发现，你用好长时间做的精细活，PM 想了想，各种原因，砍掉了。。。

举个例子，一个车载音乐播放器，PM 要求绘制音频频谱，这个绝对不是主线需求，音乐播放器，能稳定播放音乐，绝对是压倒一切其它需求的主线需求，如果一上来，你就忙着绘制频谱，而不是实现音频播放模块，那一定是本末倒置了。需要调整一下任务计划了。

三、研发中踩过的坑，如果有效避免第二次掉坑？

代码不糊弄人，人也不要糊弄代码，啥？你又掉坑里了？不长记性！

我们要做到知其然，知其所以然，对每一个踩过的坑，我们要知道这个坑产生了怎样的影响，为啥我们会掉坑。只有对每个坑有个充分的认识，并深刻领悟，才能避免我们不断的掉坑。

刚入行时，一个程序输出异常，我常用的方式就是网上胡乱搜索一通用 n 种大牛神贴提出的解决思路，来解决我遇到的 bug，然而不注意积累，不注意举一反三，当时把问题解决了，过了几个月，又掉坑里了！

每次踩坑，一定要写一下自己的踩坑日记，咋掉进去的，通过啥方式爬出来的，以后怎么避免，等等，这样即使以后又掉进去了，查查日记，还是可以快速爬出来的… 有道云笔记，推荐大家使用！

还有，别人刚从坑里爬出来，你又掉进去了，这种情况，我们也要避免，别人当年踩过的坑，也是和我们相关的。你踩过的坑，团队的其它小伙伴也需要学习。有些弯路不一定非得自己走，有些坑也不一定非得自己跳，别人的经历或许就会成为我们的经验，知道多一点，也会避开很多坑。

可以通过 bug case study 的方式，把自己踩过的坑和大家描述一下，一起学习，也更加加深自己对踩坑经历的认识。

四、常常为了一个小小的错误用了很长的时间，不知从那里查，也查不出结果，对于偶现或是小错误，是否值得投入、评判标准是什么？

如果有优先级更高的任务，那么先做其他任务，我们每个人，都有通过潜意识思考的能力。

高考时，老师会让大家在答题之前，去看一遍作文题，再从前往后作答，这里就用到了我们潜意识思考的能力，面对 bug，我们可以先看一眼，如果很容易，立马解决，不占用大脑太多思考时间，如果有难度，把问题记下来，可以先做其他任务，你放心，你的潜意识，会在你吃饭时，坐车时，甚至睡觉时去帮助你思考。

如果一个 bug，解了好久，还是没有进展，不妨看一看 TodoList 任务清单，有没有更紧急的任务。

另外如果 bug 仅仅是偶现，可以评估影响面，和 PM 商量是否解决，之前我做系统时，一个内部系统，每天上万次录音操作，只有一个电脑录音出 bug，我用了一整天时间，不知问题出在哪里，作为一个强资源，耗在一个 bug 上，肯定是不合适的，pm 决定给内部员工换台电脑，最低成本解决了…

五、常常做出来的程序，涉及到需求变动就挠头，怎么在程序设计阶段，考虑好扩展性？

如果你开发的系统，需求不是很明确，建议采用快速原型的开发方式进行开发，对功能不停的细化。

程序的扩展性建立在对业务需求变化的预见性之上。作为一名 RD，需要了解业务，有产品思维，可以琢磨出产品未来发展方向。

在入组之前，需要向 PM 和业务人员请教一下未来业务发展方向，竞品都有哪些功能。

重视程序架构设计，“ 正交设计、类要有专职、善于用委托 ”，“ 解耦、解耦 "，“ 组件化 ”，“ 数据层、业务层分层设计 ” 等等，一定要烂熟于心，Gof23 种常用设计模式，可以信手拈来，但切忌东拼西凑，一定要适合。

一般来讲，没有听说过、或者设计模式掌握不好的 RD，开发的程序，扩展性都会比较差，内功修习也很重要，一定要拿一本介绍设计模式的书，翻烂它。

 六、熬夜赶工，是否可取？

熬夜赶工，是否可取？答案当然是不可取。

没有熬过夜的程序员不是好程序员，晚上熬夜加班都已经成为程序员的名片了。不是有个段子吗，大晚上还在工作的除了盗贼，就是程序员。

工作这些年，加过很多班，可是问自己，真的加班越多，效率越高么？

答案其实是看状态的，状态好的时候，加班的效率，确实是很高的，白天的时间过于碎片化，一会儿开排期会、一会儿开沟通会、一会儿来一个面试，很难集中精力。而下班后，周围变得很安静，静下心来写代码，整个过程感觉还是不错的，经常感觉，如果可以，希望夜晚再长些，从晚上 7 点开始，再多来几个小时，让我安静的把这些需求实现完。

但是一定不要鼓励加班，尤其是很多领导，鼓励下属加班，我认为是不可取的，状态好就多干点儿、状态不好，需要及时休息。 切忌在状态不好时玩命加班，亲身体会，状态不好时，效率是很低的，作为一名 RD，要时刻感知自己的状态，状态好时，做最有挑战的事情，状态一般时，处理最有把握的事情，状态很差时，要休息一会儿。

曾经为了快速出活，每天晚上干活到三四点、早上 7 点多起来，萎靡不振，一直感到很疲倦，后来调节了一下作息，感到疲惫时，及时入睡，第二天早两小时起床，感觉状态是很不一样的。 如果长期加班，仅仅是因为每天订的目标完不成，那么我还有以下几个建议供参考：

1.每日工作前做好时间规划，写一个 TODOLIST，将任务按照优先级排序，充分利用白天的工作时间。

2.如果需要集中注意力，为避免其它事务打扰，可以选择戴上耳机、关掉 QQ、微信等，集中一两个小时的精力。

3.人们常说今日事今日毕，但是我有不同的观点，竟可能遗留 TODOLIST 上一两个任务留给明天，这样下班后，你的潜意识还是会帮你思考今天未完成的任务的，等第二天上班，可以很快的衔接前一天的工作，不至于前一天工作都做完了，第二天一上班，不知道今天要从哪个任务继续。

 七 一个功能，要不要自测，自测要多久，为什么 RD 排斥自测？

一个功能，必须经过自测，代码也最好 code review。

QA 发现一个 bug，你猜了猜原因，然后直接去修改代码，很有信心的打包，然后就丢给 QA 同学继续测试了，结果第一次 QA 说，bug 没有解决，第二次 QA 说，bug 还是没有解决，第三次 QA 怒了，你们 RD 能不能测试一下自己的东西再给我们。结果测试很不开心，你也很不开心，悄悄的嘀咕，你们 RD 不就是负责测试的吗，提BUG是你们的工作呀。

说到自测，RD 很多时候测一下自己的函数返回是不是正确，直接就给 QA 同学了。稍有不慎，修改一个函数会影响其它流程、甚至是主流程，所以提交给 QA 同学之前，一定要跑一下测试用例。提测时，也需要和 QA 说明，修改了哪些地方，会对哪些地方造成影响，便于 QA 同学制定回归计划。

什么？不知道会影响哪些地方？那么这个 BUG，修复过程一定没有走心，不清楚改目前的bug对别的功能有什么影响，就改代码，绝对是应该禁止的。以防拆东墙补西墙，改一个 BUG，冒出一堆 BUG。

修改 BUG，应该把自己当作是一个外科医生，没有充分的把握，是不能给患者开颅的，哪怕你知道患者的脑子有问题。一定要提前预估影响，平衡利弊。

切不可认为 RD 就是编码实现的，QA 才是测 BUG 的，自测是 RD 工作的一部分，最牛的 RD，是拿到 QA 哪里挑不出 BUG，而不是开发的程序，到 RD 那里一堆堆 BUG。

且 RD 也要懂得发现和使用一些自动化测试的工具，越早发现 BUG，bug 的修复成本越小，RD 应该自测，应该充分自测，最好自己的交付零 bug。

八 团队协同开发，如何向上或向下管理，提高开发效率？

向上或是向下管理，我认为核心就是两个词，目标、方案沟通。

 对于目标，从上到下，对目标的认识一定要一致，无论是你的下属还是领导，一定要统一对目标的认识。我们要在什么时间交付什么样的产品，哪些是必须交付的，哪些是可以接受 delay 或者不做的。

目标很重要，首先你需要了解领导想要达成的目标，领导需要你帮忙开发一个文本编辑器、你给领导开发了一个 Word；领导只是想让你做一个可以播放声音的工具，你给领导做了一个音频编辑器；领导只是想出一个报表，你做了一个 Excel 给他，显然你耗费了比领导预期更多的资源，开发了一个功能过载的产品。

方案沟通，也很重要，对于一个需求，领导认为开发一个小程序就可以，你认为需要开发一个 APP，甚至你认为最好还可以有个 Html5 网站，这个时候就需要和领导沟通清楚你的方案了。

RD 天天敲代码，表达能力差，不善于沟通，这是大家对 RD 的普遍认识。

我想说，不是这样，一名好的 RD，一定是逻辑性很强，表达能力最优秀的同学。写代码不是在写散文，其它人看半天，不懂是什么意思。写代码我感觉应该像是写证明题一样，别人可以按图索骥，一步步的知道，每行代码的意思，整个代码框架是什么样的。

所以，我出技术方案的时候，一般都要考虑很长时间，不会看到需求就开始做，先把技术方案想清楚，会用到哪些技术，技术难点有哪些，哪些是需要验证的，验证不通过怎么办等，然后再拿去和领导、团队小伙伴沟通。

沟通会很有必要，会议前把自己的技术方案想清楚，写成 PPT 或简单的写个提纲，提前想想在会议上大家可能的疑问有哪些，大家不支持的话，怎么说明自己的考虑 。找个大家状态都不错的时候，召集所有干系人，开会沟通一下。

对于向下、向上管理，要远离几个雷区：

1. 不是领导说啥就是啥，领导说我们今年要造个火箭，那我们要先耐心的听一下领导说的方案，提出疑问，看看是不是领导某些方面没有考虑到。如果领导不能自圆其说，相信他很乐意听你的意见。

2. 不是你说啥，下属就要答应啥。很多 RD，刚刚做管理的时候，很讨厌听反对意见、感觉自己安排什么，下属就必须做什么，甚至先做啥，后做啥，都不能给下属自由度。这样很危险，长期以往，下属会习惯唯命是从，缺乏思考。

3. 内心有想法，但是出于对领导的敬畏，不表示出来，怕自己说出反对想法，领导不高兴。这个，首先，你是帮领导出谋划策的，而不仅仅是一个执行人员。其次，任务的结果，是大家一起共担的，早一点给领导建议，早一点发现问题呢。

只有大家对目标、对方案的认识保持高度一致，做事情的效率才可以提高上来，试想一架马车，领导想往南边拉，有人往北边使劲、有人往东边使劲、有人往西边使劲，很费力的，很多会是无用功。

最后和大家分享知乎 ershou 大神的一段话，是很多新程序员不知道的小技巧，毕竟代码做到零 bug，那么效率才是最高的。

1. 东西交付之前偷偷测试一遍； 2. 问别人之前偷偷谷歌一下； 3. 版本发布之前反复检查七八遍，用 check-list； 4. 用谷歌，用英文搜索； 5. 做十件事不如做好一件事，夺取话语权只有一条路径，就是超出别人的预期； 6. 心要皮实，但话语和脸皮要柔软，记住有句老话叫，伸手不打笑脸人。 7. 先假装你就是专家，慢慢为了装得像，不得不去学，假的就成真了。

本文完，感谢你花时间把本文看完，如果你有收获或者有不同的见解，欢迎和我交流。